如何在 Ubuntu 14.04 上使用 NSD,一个仅权威的 DNS 服务器

即使对于经验丰富的管理员来说,设置负责域名的 DNS 服务器也可能是一项复杂的任务。 DNS 区域管理是一项至关重要的职责,但可能会令人困惑,尤其是在尝试开始时。

Bind DNS 服务器之类的软件非常灵活,可以配置为运行整个 DNS 层次结构中的许多组件。但是,这种灵活性也意味着 Bind 没有针对任何一项任务进行优化。这有一些副作用。

大多数时候,您的配置不需要大量功能。这种额外的复杂性使管理更加困难。这也意味着软件本身对任何一项任务的响应都会降低。

为了解决这个问题,已经创建了专门用于单个 DNS 解析领域的替代 DNS 服务器。一款名为 NSD 的软件是仅权威的 DNS 服务器,非常适合权威地管理 DNS 区域。无需担心递归或缓存,该服务器以高性能和低占用空间运行。

在本指南中,我们将演示如何安装和配置 NSD 以安全地管理 Ubuntu 14.04 服务器上的 DNS 区域。

在开始阅读本指南之前,您应该熟悉一些基本 DNS 概念和术语。如果您需要帮助了解仅权威 DNS 服务器的用途,请查看我们的指南DNS 服务器类型之间的差异。

作为仅权威的 DNS 服务器,NSD 不提供任何缓存、转发或递归功能。它只响应对其控制的区域的迭代请求。它还可以将解析器引用到它已委派出去的区域的其他名称服务器。

出于本指南的目的,我们将使用 NSD 软件配置两台服务器,作为我们区域的主服务器和辅助服务器。我们还将提供配置数据,让客户端可以访问第三台主机上的 Web 服务器。

我们将在本指南中使用虚拟域example.com。您应该替换自己的域来跟随。我们将要配置的机器将具有以下属性:

目的

DNS FQDN

IP地址

主名称服务器

ns1.example.com。

192.0.2.1

辅助名称服务器

ns2.example.com。

192.0.2.2

网络服务器

www.example.com。

192.0.2.3

完成本指南后,您应该将前两个服务器配置为 NSD,以充当您区域的仅权威服务器。您将能够使用我们配置的主机名从 Internet 访问您的服务器,并通过查询 IP 地址找出主机名。任何能够访问我们服务器的解析客户端都将能够从我们的服务器获取域数据。

我们需要采取的第一步是准备工作。在担心 DNS 配置之前,我们需要确保我们的名称服务器可以按照我们需要的方式正确解析自己的主机名。

在您的第一台 DNS 服务器上,编辑/etc/hosts文件以设置此计算机的 FQDN:

在我们的例子中,我们需要将192.0.2.1IP 地址映射到我们的第一个名称服务器的全名ns1.example.com。我们可以通过将指定主机名的行替换为我们的公共 IP 地址、FQDN 和我们的简称主持人:

完成后保存并关闭文件。

接下来,我们需要仔细检查/etc/hostname文件:

这应该包含我们的 _ unqualified _ 主机名的值。必要时修改它:

完成后保存并关闭文件。

如果你修改了上面的/etc/hostname文件,告诉系统重新读取文件:

我们暂时完成了我们的第一个 DNS 服务器。在第二台服务器上重复这些步骤。

修改/etc/hosts文件以指定第二个 DNS 服务器的主机:

还要检查/etc/hostname文件。这应该只有简短的不合格名称:

同样,如果您必须修改任何内容,请让系统重新读取文件:

您的服务器现在可以在不使用 DNS 的情况下解析自己的名称。您现在已准备好在您的服务器上设置 NSD。

下一步是在您的名称服务器上实际安装软件。

在开始之前,我们实际上必须采取额外的准备步骤。存储库中的 NSD 包会安装软件、配置一些组件并尝试启动服务。该服务希望以名为nsd的用户身份运行,但该程序包实际上并未创建此用户帐户。

为避免安装时出错,我们将在安装软件之前_创建此用户。在您的每台机器上,通过键入以下内容创建nsd系统用户:

这将创建成功完成安装所需的正确帐户。

现在,我们只需要安装 NSD 软件。幸运的是,NSD 包含在 Ubuntu 14.04 存储库中,因此我们可以使用apt将其拉下。我们将更新我们的本地包索引,然后下载相应的包:

这将安装软件并进行一些初始配置。它还将启动服务,即使我们尚未将其配置为提供任何服务。

我们将首先设置我们的ns1服务器,它将被配置为我们区域的主 DNS 服务器。

我们应该做的第一件事是确保生成 NSD 用于在应用程序的守护程序部分和控制器之间安全通信的所有 SSL 密钥和证书。

为此,请键入:

/etc/nsd目录中可能已经存在密钥和证书,但是此命令将生成缺少的任何内容。

NSD 的主要配置文件是一个名为nsd.conf的文件,位于/etc/nsd目录中。

这个目录中已经有一个文件只包含一些注释,但我们将使用一个更完整的注释示例文件作为我们的模板。现在复制它以覆盖当前文件:

现在,使用 sudo 权限在文本编辑器中打开新文件:

在内部,您将看到许多已注释的配置行组织成部分。主要部分是server、remote-control、key、pattern和zone。我们将使用其中的大部分进行配置。

首先,我们应该在server部分配置我们的 DNS 服务器的基本属性。我们将在默认 DNS 端口 53 上处理基本 IPv4 流量。我们将使用我们之前设置的nsd用户。其中大部分将是默认值,但我们将取消注释关联的行以使其值明确。

我们还想明确设置包含我们的区域数据的目录,以及我们的日志和 pid 文件位置。您可以为此部分设置许多其他配置选项,但我们将使其保持相对简单。随意进行其他更改。

我们的服务器部分将如下所示:

接下来,我们来看看remote-control部分。这部分有点用词不当,因为它不仅用于远程控制我们的守护进程。我们将对其进行配置以在本地控制守护进程。

首先,我们需要启用资源并设置其接口和端口号。这一切都可以通过取消注释相应的行并将control-enable指令更改为“yes”来完成。

接下来,我们可以取消注释指定密钥和证书文件的行。这些与我们运行nsd-control-setup命令时生成的文件名相匹配,一旦取消注释就不需要修改。

本节的值应如下所示:

接下来,我们将配置key部分。本部分将包含 NSD 将用于在我们的主服务器和辅助服务器之间安全地执行区域传输的密钥。

我们需要设置将使用的名称和算法。我们将在示例中使用名称demokey。我们还将使用他们选择的默认算法 (hmac-sha256)。

对于秘密本身,我们将采纳评论中关于如何安全生成秘密的建议。退出文本编辑器。在您的终端中,运行以下命令:

您将在命令的输出中收到一个随机生成的密钥:

复制上面红色的输出并再次打开您的配置文件。使用复制的输出作为secret参数的值。此部分应如下所示:

接下来,我们将设置一个简单的模式,因为我们有一些涉及辅助服务器的重复信息。我们每次都会通知我们的区域并将其转移到同一个辅助节点,因此创建一个模式是有意义的。

我们将调用我们的模式tosecondary来描述该模式的用途。我们将为每个区域单独设置名称和文件,因此我们无需担心模式中的这些。

我们想在我们的模式中设置notify参数来引用我们的辅助服务器的 IP 地址。我们还希望使用我们指定的密钥通过 TSIG 安全地传输区域。我们将以完全相同的方式设置provide-xfr参数。

最后我们的pattern部分应该是这样的:

最后,我们到达zone部分。在这里,我们配置 NSD 将如何处理我们的特定区域及其相关文件。

首先,我们将配置我们的前向区域。我们需要为我们的example.com区域设置区域。这就像在name参数下指定域本身一样简单,指定我们将用于区域文件的名称,并包括我们上面创建的模式,以便将其传输到我们的辅助服务器。

我们演示的完成前区应该是这样的:

接下来,我们可以处理反向区域。反向区域基本上是一个区域文件,它允许 DNS 软件将 IP 地址映射回客户端的主机名。通常,对于像 DigitalOcean 这样的托管,这由托管服务提供商负责。

例如,使用 DigitalOcean,您没有被委派负责一系列 IP 地址来设置反向映射。相反,如果您在控制面板中将服务器的主机名设置为您希望它映射回的 FQDN,DigitalOcean 会自动创建必要的反向映射。

您可以通过阅读Bind 权威指南的“A Bit About Reverse Zones”部分了解有关反向映射的更多信息。我们将向您展示如何为 NSD 设置反向区域以提供信息并获得更大的灵活性,即使这仅在您被委派控制 IP 块的反向映射的情况下才相关。

对于反向区域,我们取 IP 地址的前三个八位字节,将它们反转,并将它们作为子域委托添加到特殊域in-addr.arpa。这就是 DNS 系统使用与常规域相同的查找方法搜索 IP 地址的方式。对于我们的例子,我们将创建一个定义2.0.192.in-addr.arpa映射的反向区域。这看起来与前向区域规范非常相似:

完成后保存并关闭文件。

现在,我们需要创建转发区域文件。在我们的配置中,我们将区域文件命名为“example.com.zone”。我们将不得不在我们的/etc/nsd目录中创建一个具有此名称的文件。

使用 sudo 权限在文本编辑器中打开该文件:

我们需要做的第一件事是在顶部设置一些参数。我们将设置$ORIGIN参数,该参数指向我们以 FQDN 格式配置的域(以结束点完成)。我们还想设置默认的生存时间。我们将使用 1800 秒或 30 分钟:

接下来,我们需要我们的 SOA,或者权限记录的开始。这将如下所示:

这定义了一些区域范围的值。ns1.example.com.值用于指定该区域的权威服务器之一的域位置。admin.example.com.用于指定可以联系到区域管理员的电子邮件地址。

电子邮件地址,在本例中为[email protected]。在 DNS 区域文件中,“@”符号必须更改为点。结束点也很重要,因为它们在指定 FQDN 时总是如此。

括号中的值定义了我们区域的一些值。我们将在这里提到的唯一一个是序列号。每次更改区域文件时,必须增加此值。在这里,我们使用撰写本文的日期(2014 年 7 月 2 日)加上修订号进行演示。

接下来,我们需要使用 NS 记录来定义对该区域具有权威性的名称服务器。请记住为您的域使用 FQDN,包括结束点:

接下来,我们需要设置 A 记录,它实际上会告诉客户端如何访问我们指定的名称服务器。这就是将我们的主机名映射到其实际 IP 地址的原因:

最后,我们要为我们的其他主机添加任何额外的 A 记录。在我们的例子中,我们将设置我们的基本域 (example.com) 和www主机名以映射到我们的 Web 服务器:

完成后,您完成的文件应如下所示:

完成后保存并关闭文件。

接下来,我们将为我们的反向区域制作一个类似的文件。请记住,只有当您被委派负责地址块的反向映射时,才需要这样做。

创建您在nsd.conf文件中引用的反向区域文件,并在文本编辑器中使用 sudo 权限打开它:

同样,我们将从定义$ORIGIN和$TTL参数开始。这一次,请记住为您的区域将源设置为in-addr.arpa子域。在我们的例子中,这将如下所示:

接下来,我们需要像以前一样设置 SOA 记录。我们几乎可以对这个文件使用完全相同的值,因为相同的电子邮件和权威名称服务器负责这两个区域。此外,数值也应该在这种情况下起作用。请记住,每次进行更改时都要修改序列号:

完成后,文件应如下所示:

同样,我们需要定义对区域具有权威性的名称服务器。这些将再次成为相同的服务器:

最后,我们需要通过使用 PTR 记录将每个 IP 地址的最后一个八位字节路由到关联主机的 FQDN 来提供实际的反向域映射:

完成后,文件应如下所示:

完成后保存并关闭文件。

现在我们已经配置了主服务器,我们可以继续测试我们的配置文件并实现我们的更改。

您可以使用附带的nsd-checkconf工具检查主配置文件的语法。只需将该工具指向您的主配置文件:

如果这立即返回而没有输出,则意味着您的主配置文件的语法是有效的。如果出现错误,请检查配置文件的语法以修复任何错误。

在您能够干净地执行检查后,您可以通过键入以下内容重新启动服务:

这将停止并启动 NSD 守护程序。

检查日志以查看任何消息:

您应该会看到一些如下所示的错误:

这是因为 NSD 正在尝试将区域传输到尚未配置的辅助服务器。

现在我们已经设置了主服务器,我们可以继续准备辅助服务器。

同样,我们要确保我们的 SSL 证书和密钥都已生成且可用。为此,请发出以下命令:

这将确保我们可以使用控制守护程序所需的所有凭据文件。

辅助服务器的nsd.conf文件与主服务器基本相同。我们只需要修改几件事。首先将主服务器的/etc/nsd/nsd.conf文件复制到辅助服务器的/etc/nsd/nsd.conf文件中。

该辅助服务器的文件现在应如下所示:

这几乎正是我们所需要的。

server、remote-control和key部分已完全配置。key部分中的“秘密”_必须_与主服务器的值匹配,因此复制完整的文件内容很容易满足这一要求。

我们需要修改的第一件事是pattern部分。我们复制的部分特定于主服务器,因此我们想要修改它以从辅助服务器的角度解决问题。

首先,将名称更改为更具描述性的名称。我们将使用相同的约定并将其称为fromprimary。我们还需要更改此设置的指令。辅助服务器不需要notify参数,而是需要一个allow-notify参数,该参数指定允许通知它的服务器。我们仍将使用相同的密钥,因此我们只需要修改名称和适当的 IP 地址。

以类似的方式,我们需要将provide-xfr参数更改为request-xfr。其格式略有变化。我们需要指定我们想要一个 AXFR 传输(NSD 主节点能够进行的唯一类型)并且我们需要指定 IP 地址_和_主节点的端口号。

完成后,pattern部分将如下所示:

对于zone部分,我们唯一需要修改的是include-pattern以匹配我们刚刚创建的新模式:

完成后,保存并关闭文件。

由于我们的辅助服务器将通过主服务器的传输接收其所有区域数据,因此我们实际上不需要在此主机上配置区域文件。

同样,我们应该通过键入以下内容检查主配置文件的语法:

如果您收到任何错误,您需要再次查看您的nsd.conf文件以解决语法问题。如果命令返回而没有任何输出,则表示您的语法在文件中有效。

当您的配置文件通过测试时,您可以通过键入以下内容重新启动服务:

检查日志以确保一切正常:

现在,您的仅权威 NSD 服务器应该已配置好并准备好提供有关您的域的 DNS 信息。我们仍然需要配置您的域,以便它知道使用您的名称服务器。

为此,您需要调整购买域名的注册商下的一些设置。一些术语,当然界面也会因注册商而异,但如果您仔细查看,您应该能够找到设置。

我将演示如何使用相当标准的域名注册商Namecheap来做到这一点。

我们需要以允许我们在域的父级设置粘合记录的方式调整您的名称服务器。每当名称服务器在域内_within_ 时,这都是必要的。

当您委派子域时(例如com域中的example.com),您必须指定对该域具有权威性的名称服务器。如果名称服务器在域内,您_也_必须包含粘合记录,它只是每个名称服务器的 A 记录,对委派区域具有权威性。

我们需要这个,因为如果不包含粘合记录,DNS 查找会陷入循环。客户会询问我们的注册商谁对域example.com具有权威性,我们的注册商会(在我们配置后)返回ns1.example.com和ns2.example.com。如果我们不包含 A 记录来将这些解析为 IP 地址,那么客户将永远无法移动超越这个点。它无法找到它需要的名称服务器的 IP 地址,因为这些通常是在名称服务器本身中定义的。

您可以在注册商界面中配置名称服务器的位置_和_与它们关联的 IP 地址将因您的提供商而异。使用 Namecheap,有一个名为“Nameserver Registration”的部分允许您设置名称服务器的 IP 地址以创建粘合记录:

在这里,您可以设置名称服务器并将它们映射到特定的 IP 地址:

完成此操作后,您需要设置用于您的域的活动名称服务器。 Namecheap 有一个名为“域名服务器设置”的选项,可以完成以下任务:

在选择该选项时出现的界面中,您可以输入刚刚注册的名称服务器的主机名:

您对注册商所做的更改可能需要一些时间才能传播。数据还需要额外的时间才能传播到世界其他地方的 DNS 服务器。通常,此过程应在接下来的 24-48 小时内完成。

使用本指南,您现在应该拥有一个主要和次要的仅权威 DNS 服务器,可用于提供有关您的域的 DNS 信息。与 Bind 不同,NSD 针对高性能权威行为进行了优化,因此您可以获得针对您的需求进行调整的更高性能。